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Steuergerat und Computerproqramm zum S teuern eines 
Antriebsaggregates eines Fahrzeuqs 



Die Erfindung betrifft ein Steuergerat und ein Computerprogramm 
zum Steuern eines Antriebsaggregates, insbesondere einer 
Brennkraf tmaschine eines Fahrzeugs . 

Stand der Technik 

Derartige Steuergerate und zugehOrige Computerprogramme sind im 
Stand der Technik grundsatzlich bekannt. Figur 9 zeigt ein 
derartiges bekanntes Steuergerat, wobei das Bezugszeichen 100a 
die Hardware und das Bezugszeichen 100b die Software des 
Steuergerates 100 reprasentiert . Die Hardware des Steuergerates 
100 umfasst wenigstens einen Prozessor 100a-l und wenigstens ein 
Speicherelement 100a-2. Die Software 100b ist ublicherweise in 
dem Speicherelement 100a-2 hinterlegt. Die Software 100b umfasst 
im Stand der Technik Ublicherweise eine Vielzahl von 
Funktionseinheiten VF-1, EF-3, IS-2, HWE-1, HWE-3 und VF-3, die 
zumindest vereinzelt zum Zwecke der Ansteuerung des 
Antriebsaggregates 300 miteinander kommunizieren. Die 
unmittelbare Steuerung des Antriebsaggregates 300 erfolgt mit 
Hilfe einer zwischen das Steuergerat 100 und das 

Antriebsaggregat 300 geschalteten Sensor-/Aktor-Konf iguration 
200. 

Bekannte Funktionseinheiten in der Software 100b far ein 
Steuergerat 100 zum Steuern eines Antriebsaggregates sind 
beispielsweise: 
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Funktionseinheit Antrieb VF-1: Sie verwaltet die Quellen 
mechanischer Energie und stellt fUr das Antriebsaggregat 
ein Sollmoment zum Vortrieb des Fahrzeugs und zur 
Versorgung der Nebenaggregate, liblicherweise nach Vorgabe 
durch eine Funktionseinheit Fahrzeugkoordinator, zur 
Verfiigung. 

Funktionseinheit Fahrzeugkoordinator VF-2: Sie trifft 

Entscheidungen liber das Zusammenwirken verschiedener, auch 

anderer Funktionseinheiten. Beispielsweise entscheidet 

sie, welches Moment die Funktionseinheit Antrieb bei dem 

Antriebsaggregat einstellen soil, wenn verschiedene andere 

Funktionseinheiten jeweils unterschiedliche 

Momentenbetrage bei dem Antriebsaggregat einzustellen 
f ordern . 

Funktionseinheit Fahrzeugbewegung VF-3: Sie vergleicht 
eine aktuelle Bewegung des Fahrzeugs mit den Wtinschen des 
Fahrers im Hinblick auf die Gewahrleistung einer optimalen 
Fahrstabilitat. Hierzu gehort zum Beispiel die Auswertung 
des Fahrerwunsches gemaii Aktionen am Gas- und Bremspedal 
sowie die Koordination dieses Fahrerwunsches mit Vorgaben 
von Sicherheitssystemen, wie elektronisches 
Stabilitatsprogramm ESP oder Antischlupf regelung ASR. 
Funktionseinheit FahrzustandsgrGfien VF-4: Sie verwaltet 
die Informationen iiber aktuelle Fahrzustande, zum Beispiel 
Stop & Go, Fahrt bergauf et cetera, unabhangig davon, 
welche Funktionseinheit diese Fahrzustande ermittelt. 
Funktionseinheit Motorkoordinator EF-1: Der 
Motorkoordinator hat die Aufgabe, alle Betriebszustande 
des Motors zu koordinieren und Informationen ttber den 
Motorbetriebszustand zur Verfiigung zu stellen. 
Funktionseinheit Motormomentenstruktur EF-2 : Diese 
Funktionseinheit hat die Aufgabe, die Momenten- 
Anforderungen von anderen Funktionseinheiten an den Motor 
zu ermitteln und zu koordinieren und eine resultierende 
Anforderung an die Momentenumsetzung zu ermitteln. 
Aggregat-Positions-Management EPM: Diese Funktionseinheit 
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hat die Aufgabe, eine Positions- und Drehzahlerfassung der 
Kurbel- und Nockenwelle des Antriebsaggregates 
durchzuf iihren . 

. Funktionseinheit Dienstebibliotheken is-l: sie hat die 
Aufgabe, allgemeine, sehr haufig verwendete Funktionen 
bereitzustellen, die von unterschiedlichen 
Funktionseinheiten nachgefragt beziehungsweise benutzt 
werden. Sie bietet eine zentrale Bereitstellung dieser 
Funktionen mit dem Vorteil, dass diese nicht mehrfach 
dezentral bereitgestellt werden mttssen. 

Funktionseinheit Ablauf steuerung IS-2: Sie koordiniert die 
zeitliche Abarbeitung von Anforderungen unterschiedlicher 
Funktionseinheiten. 

Funktionseinheit Diagnosemanager IS-3: Diese 
Funktionseinheit ubernimmt die Aufbereitung eines 
Fehlersignals, welches zum Beispiel einen Defekt in der 
Hardware 100a des Steuergerates 100 reprasentiert . Die 
Aufbereitung besteht insbesondere in einer Entprellung des 
Fehlersignals und einer Abspeicherung desselben, damit zu 
einem spateren Zeitpunkt eine Auswertung des Fehlersignals 
erfolgen kann. 

Funktionseinheit Oberwachungskonzept IS-4: Diese 
Funktionseinheit dient insbesondere der ©berwachung des 
Prozessors des Steuergerates. 

Funktionseinheit Signalaufbereitung HWE-1: sie filhrt eine 
Bereinigung eines analogen Sensorsignals nach dessen 
Digitalisierung durch im Hinblick auf unerwunschte 
Signalmodulationen, die in dem Steuergerat eventuell 
entstanden sein konnen. 

Funktionseinheit Gassystem EF-3 : Sie hat die zentrale 
Aufgabe, Informationen tiber die aktuell ftir das 
Antriebsaggregat 300 zur Verfugung stehende Luftmasse zu 
liefern und im Rahmen ihrer Einf lussmoglichkeiten auf das 
Antriebsaggregat eine gewunschte Soll-Luf tmasse und/oder 
die Abgasqualitat zu uberwachen oder einzustellen. Diese 
Funktionseinheit Gassystem wird insbesondere bei 
Dieselmaschinen oder Benzinmaschinen verwendet. 
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• Funktionseinheit Einspritzsystem EF-4: Sie stellt alle 

Funktionen bereit, welche zur Kraftstof fvorforderung, 

Einspritzdruckerzeugung und Einspritzung erforderlich 
sind. 



Einzelne dieser bekannten Funktionseinheiten sind in Figur 9 
innerhalb der Software 100b des Steuergerates beispielhaft 
veranschaulicht. Sie wurden jedoch nicht alle gleichzeitig 
entwickelt und in der Software 100b implement iert, sondern sind 
erst im Laufe der Zeit im Zuge fortschreitender Entwicklung 
sukzessive zu der Software des Steuergerates 100 hinzugefugt 
worden. Bei der Hinzufiigung neuer Funktionseinheiten hat man 
bisher lediglich darauf geachtet, dass die neuen 
Funktionseinheiten mit alien anderen Funktionseinheiten, soweit 
erforderlich, kommunizieren konnten. Im Laufe der Zeit entstand 
so ein unUbersichtliches Agglomerat von Schnittstellen zwischen 
den einzelnen Funktionseinheiten, was insbesondere einen 
Austausch bekannter Funktionseinheiten durch modifizierte 
Funktionseinheiten oder die weitere Hinzufugung von neuen 
Funktionseinheiten zunehmend schwieriger machte. Die 
Schwierigkeiten entstanden insbesondere deshalb, weil bestehende 
Abhangigkeiten zwischen einzelnen Funktionseinheiten bei einer 
Umgestaltung des Gesamtsystems oder auch nur von Teilen 
desselben nur noch sehr schwer Oberschaubar waren. 

Ausgehend von diesem Stand der Technik ist es die Aufgabe der 
vorliegenden Erfindung, ein bekanntes Steuergerat und ein 
Computerprogramm zum Steuern eines Antriebsaggregates eines 
Fahrzeugs derart weiterzubilden, dass einzelne Teile des 
Steuergerates und insbesondere von dessen Software unabhangig 
voneinander realisierbar und austauschbar sind. 

Diese Aufgabe wird durch den Gegenstand des Patentanspruchs 1 
gelost. Demnach ist far ein oben beschriebenes bekanntes 
Steuergerat eine Modularisierung in Form von mindestens drei 
Modulen vorgesehen, wobei in einem ersten Modul diejenigen 
Funktionseinheiten zusammengefasst sind, die zur Beeinf lussung 
des Antriebsaggregates im Ansprechen auf einen Benutzerwunsch 
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auf physi kalis cher Ebene dienen, in einem zweiten Modul 
diejenigen Funktionseinheiten zusammengefasst sind, welche eine 
individuelle Programmierung der Hardware des Steuergerates in 
der Weise ermoglichen, dass die Hardware in die Lage versetzt 
wird, mit den Modulen des Steuergerates zu kommunizieren und 
welche die Abarbeitung von Funktionen der Funktionseinheiten in 
den Modulen zeitlich koordinieren und in einem dritten Modul 
diejenigen Funktionseinheiten zusammengefasst sind, die eine 
individuelle Anpassung der verwendeten Sensor-/Aktor- 
Konfiguration an das Steuergerat in der Weise ermoglichen, dass 
zwzschen den einzelnen Sensoren oder Aktoren der Konfiguration 
eine Kommunikation mit den ubrigen Modulen des Steuergerates 
mOglich ist; und wobei zwischen den Modulen Modul-Schnittstellen 
fUr eine modul -ubergreifende Kommunikation vorgesehen sind. 

Das Antriebsaggregat im Sinne der Erfindung kann alternativ zu 
eaner Brennkraftmaschine auch zum Beispiel einen Elektroantrieb 
Oder einen Brennstof f zellenantrieb reprasentieren. 

Benutzer im Sinne der Erfindung kann zum Beispiel der Fahrer des 
Fahrzeugs, der Gesetzgeber, ein Fahrzeugzulief erer oder ein 
Fahrzeughersteller sein. 

Physikalische Ebene im Sinne der Erfindung bedeutet eine 
Abstraktion von Hardware-Spezifika. Dies bedeutet, dass in der 
physikalischen Ebene, bezogen auf die Schnittstelle des Sensors 
zu seiner Omgebung, lediglich physikalische GrOIien wie zum 
Beispiel die Drehzahl des Antriebsaggregates betrachtet werden, 
nxcht jedoch deren hardwaremaJJige Realisierung in Form eines 
elektronischen Signals mit einer hardware-spezif ischen, die 
Drehzahl reprasentierenden Amplitude. 

Vorteile der Erfindung 

Der wesentliche Vorteil der beanspruchten Modularisierung 
besteht darin, dass die einzelnen Module einfach austauschbar 
und unabhangig voneinander realisierbar sind. Dabei wurde die 
Aufteilung der Funktionseinheiten auf die einzelnen Module so 
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gewahlt, dass sie insbesondere aus Sicht der Fahrzeughersteller 
und aus physikalischer sicht sinnvoll ist. Ein Austausch 
einzelner Module ist insbesondere deshalb besonders einfach, 
weil in den definierten Modul-Schnittstellen zwischen den 
einzelnen Modulen alle Abhangigkeiten zwischen den 
Funktionseinheiten in den verschiedenen Modulen beriicksichtigt 
sind; daraber hinausgehende Abhangigkeiten kSnnen zwar noch auf 
Ebene der Funktionseinheiten existieren, sind aber auf Ebene der 
Module nicht mehr existent und brauchen deshalb bei einem 
Austausch der Module nicht mehr beriicksichtigt zu werden. 

Mit der vorgeschlagenen Modularisierung sind insbesondere 
Kosten- und Zeitersparnisse verbunden. Bei Verwendung einer 
anderen Steuergeratehardware oder einer anderen Sensor-/Aktor- 
Konfiguration braucht nun nicht mehr die gesamte Software des 
Steuergerates ausgetauscht oder angepasst zu werden, sondern es 
ist vielmehr ausreichend, wenn nur das entsprechende Modul 
ausgetauscht wird. 



Gemafi einem ersten Ausftihrungsbeispiel wird vorteilhaf terweise 
vorgeschlagen, das erste Modul in eine Fahrzeug-Komponente und 
xn erne Antriebsaggregate-Komponente zu unterteilen. GemaJJ einem 
zweiten Ausftihrungsbeispiel wird vorgeschlagen, das zweite Modul 
xn erne Infrastruktur-Komponente und in eine Hardwarekapsel 
sowie optional zusatzlich eventuell auch noch in eine 
Kommunikations-Komponente zu unterteilen. 

Zusammenfassend zu den vorgenannten Ausfuhrungsbeispielen ist 
anzumerken, dass die Unterteilung der einzelnen Module in 
Komponenten ahnlich wie bei den Modulen dazu dient, die 
Austauschbarkeit der Komponenten zu verbessern. 

Vorteilhafterweise sind auch zwischen den Komponenten innerhalb 
eines Moduls Schnittstellen fur einen schnellen Datenaustausch 
vorgesehen. Dagegen erfolgt eine Kommunikation zwischen 
Komponenten in unterschiedlichen Modulen tiber die Modul- 
Schnittstellen. Jede der Komponenten ist ihrerseits wiederum in 
belxebrg viele Funktionseinheiten unterteilt. Schnittstellen 



4 > ' 



R305251 



sind auch auf Ebene dieser Funktionseinheiten vorgesehen, so 
dass verschiedene Funktionseinheiten innerhalb einer Komponente 
miteinander kommunizieren k6nnen. Eine Kommunikation zwischen 
Funktionseinheiten in unterschiedlichen Komponenten erfolgt uber 
die Komponentenschnittstellen und eine Kommunikation zwischen 
Funktionseinheiten in unterschiedlichen Modulen erfolgt uber die 
Modul-schnittstellen. Auch fur die Schnittstellen zwischen den 
Funktionseinheiten und zwischen den Komponenten gilt das bereits 
oben fur die Modul-Schnittstellen Gesagte, namlich dass in 
diesen Schnittstellen alle notwendigen Abhangigkeiten zwischen 
den Funktionseinheiten oder Komponenten untereinander 
beriicksichtigt sind und jeweils weitere Abhangigkeiten nicht 
beriicksichtigt werden mtissen. Daraus resultiert eine einfache 
Austauschbarkeit nicht nur von Modulen, sondern auch von 
Komponenten oder Funktionseinheiten, das heiJit insbesondere eine 
einfache und unkomplizierte Anpassung an Kundenwttnsche oder neue 
Technologien. 



Erne nahere Beschreibung der Aufgaben der einzelnen Komponenten 
und der in den einzelnen Komponenten zusammengefassten 
Funktionseinheiten und Elemente ist Gegenstand der 
Unteransprtiche . 

GemaA einer vorteilhaf ten Ausbildung sind die 

Funktionseinheiten, die Komponenten und/oder die Module sowie 
deren jeweilige Schnittstellen zumindest teilweise als 
Computerprogramm ausgebildet. Die Ausbildung als 
Computerprogramm erlaubt eine flexible Umsetzung von 
Anderungswunschen, ohne dass eine Anderung der Hardware des 
Steuergerates vorgenommen werden muss. 

Die oben genannte Aufgabe wird weiterhin durch ein 
Computerprogramm fur das beschriebene und beanspruchte 
Steuerprogramm gelost. Die Vorteile dieses Computerprogramms 
entsprechen den oben mit Bezug auf das Steuerprogramm erwahnten 
Vorteilen. 



Weitere Vorteile ergeben sich aus der nachfolgenden 
Beschreibung. 
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Zeichnungen 

Der Beschreibung sind insgesamt- neun Figuren beigefugt, wobei 

Figur 1 eine erf indungsgemafie Modularchitektur ftir ein 

Steuergerat; 

Figur 2 eine erfindungsgemalie Unterteilung der Module in 

Komponenten; 

Figur 3 eine erfindungsgemaJie Zuordnung von 

Funktionseinheiten zu einer Fahrzeug-Komponente und 
einer Antriebsaggregate-Komponente; 

Figur 4 die erfindungsgemalie Zuordnung von Funktionseinheiten 

zu einer Infrastruktur-Komponente und einer 
Hardware kapsel -Komponen te ; 

Figur 5 eine Funktionseinheit fur ein Geratetreiber-Element; 

Figur 6 eine Veranschaulichung von Schnittstellen zwischen 

den Modulen; 

Figur 7 eine Schnittstelle zwischen zwei Funktionseinheiten 

in unterschiedlichen Komponenten; 

Figur 8 ein Beispiel fur einen Datenfluss zwischen den 

Modulen; und 

Figur 9 den Aufbau eines Steuergerates gemafi dem Stand der 

Technik 

Figur 10 die Einbettung einer erf indungsgemaJien 

Schnittstellenarchitektur in die Modularchitektur • 

Figur 11 die Schichtendarstellung einer ausgewahlten 

Schittstelle 

zeigt . 
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Beschreibung der Ausf tihrungsbeispiele 

Es folgt eine detaillierte Beschreibung von 

Ausfiihrungsbeispielen der Erfindung unter Bezugnahme auf die 
Figuren . 

Figur 1 zeigt unter Bezugnahme auf Figur 9 eine erf indungsgemafie 
Modularisierung von Funktionseinheiten in einem Steuergerat 100 
zum Steuern eines Antriebsaggregates 300, insbesondere einer 
Brennkraftmaschine, eines Fahrzeugs. Im Unterschied zu Figur 9 
ist in Figur 1 lediglich die Struktur des Inhaltes des 
Speicherelementes 100a-2 dargestellt; insbesondere die Sensor- 
/Aktor-Konfiguration 200 und das Antriebsaggregat 300 sind nicht 
Gegenstand der Erfindung und werden deshalb nachfolgend nicht 
weiter beschrieben. 

Erfindungsgemali wird vorgeschlagen, die Funktionseinheiten in 
dem Steuergerat 100 in vier separate Module zu gruppieren. 

In einem ersten Modul ASW werden diejenigen Funktionseinheiten 
zusammengefasst, die zur Beeinflussung des Antriebsaggregates 
300 im Ansprechen auf' einen Benutzerwunsch auf physikalischer 
Ebene dienen. 

In einem zweiten Modul CO werden zum einen diejenigen 
Funktionseinheiten zusammengefasst, welche eine individuelle 
Programmierung der Hardware des Steuergerates 100 in der Weise 
ermdglichen, dass die Hardware in die Lage versetzt wird, mit 
den Modulen des Steuergerates 100 zu kommunizieren . Weiterhin 
umfasst das zweite Modul CO diejenigen Funktionseinheiten, 
welche eine Abarbeitung von Funktionen der Funktionseinheiten in 
den Modulen ASW, CO, DE, CD zeitlich koordinieren. Daruber 
hinaus kann das zweite Modul CO auch solche Funktionseinheiten 
aufweisen, welche eine Kommunikation des Moduls ASW und/oder 
eines dritten Moduls DE mit anderen Steuergeraten ermbglichen. 
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In einem dritten Modul DE werden diejenigen Funktionseinheiten 
zusammengefasst, die eine individuelle Anpassung der verwendeten 
Sensor-/Aktor-Konfiguration an das Steuergerat 100 in der Weise 
ermSglichen, dass zwischen den einzelnen Sensoren Oder Aktoren 
der Konfiguration eine Kommunikation ait den tibrigen Modulen des 
Steuergerates 100 moglich ist. 

Schliefllich werden in einem vierten Modul CD diejenigen 
Funktionseinheiten zusammengefasst, die eine direkte Ansteuerung 
von komplexen Sensor-/Aktor-Konf igurationen mit komplexen 
Schnittstellen zu dem Steuergerat 100 durch das erste Modul 
ermoglichen. Diese speziellen Sensor-/Aktor-Konf igurationen sind 
von den zuvor erwahnten nicht-speziellen Sensor- /Aktor- 
Konf igurationen zu unterscheiden. Im Onterschied zu nicht- 
spezifischen Konf igurationen, bei denen eine Kommunikation mit 
dem ersten Modul nur uber das zweite und das dritte Modul ist, 
erfolgt bei den speziellen Konfigurationen eine Kommunikation' 
mit dem ersten Modul direkt uber das vierte Modul. 

Zwischen den Modulen ASW, CO, DE, CD sind jeweils Modul- 
Schnittstellen Ml, M2, M3, M4, M5 und M6 vorgesehen, die zum 
einen eine Kommunikation der Module untereinander, aber auch den 
Austausch einzelner Module ermbglichen. 

Figur 2 zeigt eine erf indungsgemaJle Gruppierung von Komponenten 
innerhalb der zuvor beschriebenen Module ASW, CO und CD. Das 
erste Modul ASW reprasentiert im Wesentlichen anwender- bzw. 
benutzerorientierte Funktionen. Im Hinblick auf geplante 
Anwendungsfalle, bei denen unterschiedliche Typen von 
Antriebsaggregaten durch das Steuergerat angesteuert werden 
sollen, ist es sinnvoll, dieses erste Modul ASW in eine 

Fahrzeug-Komponente VF und eine Antriebsaggregate-Komponente EF 
zu unterteilen. 



Die Fahrzeug-Komponente umfasst vorzugsweise diejenigen 
Funktionseinheiten, die nicht spezifisch fur einen bestimmten 
Typ von Antriebsaggregat 300 sind. Dabei handelt es sich 
insbesondere urn die Funktionseinheiten Antrieb VF-1, 



11 



R305251 



Fahrzeugkoordinator VF-2, Fahrzeugbewegung VF-3 oder 
FahrzustandsgroAen VF-4, wie sie einleitend beschrieben wurden. 

Demgegenuber sind in der Antriebsaggregate-Komponente EF 
vorzugsweise alle diejenigen Funktionseinheiten zusammengefasst , 
die fur den verwendeten Typ von Antriebsaggregat 300 spezifisch 
sind. Dabei handelt es sich vorzugsweise urn die 

Funktionseinheiten Motorkoordinator EF-1, Motormomentenstruktur 
EF-2, Gassystem EF-3 oder Einspritzsystem EF-4, wie oben unter 
Bezugnahme auf Figur 9 beschrieben. Bei einem Wechsel des von 
dem Steuergerat 100 anzusteuernden Antriebsaggregates 300 ist es 
dann nicht mehr erforderlich, das komplette erste ASW-Modul 
auszutauschen, sondern es genugt vorteilhafterweise, wenn 
lediglich die Antriebsaggregate-Komponente EF ausgetauscht wird. 

Ahnlich wie bei dem ersten Modul empfiehlt es sich bei dem 
zweiten Modul zum Beispiel im Hinblick auf einen anderen zu 
verwendenden Prozessor in dem Steuergerat 100, das zweite Modul 
in eine Infrastruktur-Komponente IS und in eine Hardwarekapsel- 
Komponente HWE zu unterteilen. In der Infrastruktur-Komponente 
IS sind vorzugsweise alle diejenigen Funktionseinheiten 
zusammengefasst, welche grundlegende Dienste anbieten oder 
reprasentieren, auf die andere Funktionseinheiten zugreifen 
konnen. Dabei handelt es sich vorzugsweise um die 
Funktionseinheiten Dienstebibliotheken IS-1, Ablauf steuerung IS- 
2, Diagnosemanager IS-3 und Uberwachungskonzept IS-4, wie 
ebenfalls oben beschrieben. Die Dienste werden in der 
Infrastruktur-Komponente an zentraler Stelle bereitgestellt und 
raussen deshalb nicht dezentral in mehrfacher Ausfertigung 
vorliegen und unnStig Speicherplatz beanspruchen. 

• 

In der Hardwarekapsel-Komponente HWE sind alle diejenigen 
Funktionseinheiten zusammengefasst, welche eine individuelle 
Programmierung der Hardware 100a des Steuergerates 100 in der 
Weise ermoglichen, dass die Hardware 100a in die Lage versetzt 
wird, mit den Modulen ASW, CO, DE oder CD des Steuergerats 100 
zu kommunizieren. So ist es bei einem Austausch des in dem 
Steuergerat verwendeten Prozessors durch einen Prozessor anderen 
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Typs lediglich erf orderlich, die Hardwarekapsel-Komponente HWE 
und nicht mehr das gesamte zweite Modul des Steuergerates 
aus zutaus chen . 



Neben der genannten Infrastruktur-Komponente und der 
Hardwarekapsel-Komponente kann das zweite Modul CO weiterhin 
eine Kommunikations-Komponente COM aufweisen, in welcher 
diejenigen Funktionseinheiten zusammengefasst sind, welche eine 
Kommunikation mit anderen Steuergeraten ermoglichen. 

Neben den bereits oben erwahnten Modul-Schnittstellen Ml ... M6 
auf Modulebene sind auch Komponentenschnittstellen auf Ebene der 
Komponenten innerhalb der einzelnen Module vorgesehen. Diese 
Komponentenschnittstellen KO ... K3 erm5glichen einen 
Datenaustausch zwischen zumindest einzelnen der Komponenten 
innerhalb eines Modul s . So besteht eine Schnittstelle KO in dem 
ersten Modul zwischen der Fahrzeug-Komponente VF und der 
Antriebsaggregate-Komponente EF. Innerhalb des zweiten Moduls 
besteht eine Komponentenschnitts telle Kl zwischen der 
Infrastruktur-Komponente IS und der Kommunikations-Komponente 
COM, eine zweite Schnittstelle K2 zwischen der Infrastruktur- 
Komponente IS und der Hardwarekapsel-Komponente HWE und eine 
dritte Schnittstelle K3 zwischen der Hardwarekapsel-Komponente 
HWE und der Kommunikations-Komponente COM. 

In Figur 3 ist die bereits erwahnte Zuordnung von 
Funktionseinheiten zu der Fahrzeug-Komponente VF und zu der 
Antriebsaggregate-Komponente sowie die Schnittstelle KO zwischen 
den beiden Komponenten dargestellt. Daruber hinaus ist 
ersichtlich, dass auch die Funktionseinheiten innerhalb einer 
Komponente tiber Funktionseinheiten-Schnittstellen Fi mit i = 1 - 
9 untereinander kommunizieren konnen. Eine Kommunikation 
zwischen Funktionseinheiten, die unterschiedlichen Komponenten 
innerhalb desselben Moduls zugeordnet sind, erfolgt Uber die 
besagte Komponentenschnittstelle, hier KO . 



Figur 4 zeigt die bereits beschriebene Zuordnung 
Funktionseinheiten zu der Infrastruktur-Komponente IS und der 
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Hardwarekapsel-Komponente HWE innerhalb des zweiten Moduls . Die 
bereits unter Bezugnahme auf Figur 3 gemachten Aussagen zu den 
Schnittstellen zwischen den Funktionseinheiten und den 
Komponenten gelten hier entsprechend. Alternativ oder zusatzlich 
zu der in den Figuren 3 und 4 gezeigten Ausbildung der 
Funktionseinheiten-Schnittstellen zwischen den 
Funktionseinheiten innerhalb einer Komponente kSnnen diese 
Schnittstellen auch derart ausgebildet sein, dass eine direkte 
Verbindung zu jeder Funktionseinheit innerhalb einer Komponente 
besteht. Fiir eine Kommunikation zwischen beispielsweise der 
Funktionseinheit Dienstebibliotheken IS-1 und der 
Funktionseinheit Diagnosemanager IS-3 ware es dann nicht 
erforderlich, uber die Funktionseinheit Ablauf steuerung IS-2 zu 
kommunizieren, sondern es stunde eine direkte Verbindung zur 
Ver f tigung . 

FUr die Funktionseinheiten HWE-1...N der HWE ist es vorteilhaft, 
diese jeweils in ein Prozessorebenenelement und ein 
Hardwareabstraktionsebenenelement zu unterteilen. Diese 
Onterteilung bietet den Vorteil, dass bei einem gewtlnschten 
Austausch des Prozessors nicht die gesamte Hardware-Kapsel- 
Komponente HWE, sondern nur die Prozessorebenenelemente, dann 
allerdings bei alien Funktionseinheiten der Hardwarekapsel- 
Komponente HWE ausgetauscht werden miissen. Analog ist es dann 
bei einem gewtlnschten Austausch der Peripheriehardware des 
Steuergerates, das ist die Hardware des Steuergerates aufier dem 
Prozessor, ebenfalls nicht mehr erforderlich, die gesamte 
Hardwarekapsel-Komponente HWE auszutauschen, sondern es geniigt 
ein Austausch der Hardwareabstraktionsebenenelemente bei alien 
Funktionseinheiten der HWE. 

Eine der Hardwarekapsel-Komponente HWE zugeordnete 
Funktionseinheit ist die Funktionseinheit Signalaufbereitung 
HWE-1, die einleitend beschrieben wurde. Fur die 
Funktionseinheit Signalaufbereitung HWE-1 ubernimmt das 
Prozessorebenenelement HWE-1-1 die Signalaufbereitung insoweit 
als sie sich auf den verwendeten Prozessortyp bezieht und das 
Hardwareabstraktionsebenenelement HWE-1-2 die Signalaufbereitung 
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insoweit als sie sich auf die im Steuergerat verwendete 
Peripheriehardware bezieht. 

Schnittstellen Ek sind weiterhin vorgesehen fur eine 
Konimunikation der Prozessorebenenelemente HWE-1-1 und der 
Hardwareabstraktionsebenelemente HUB- 1-2 untereinander und/oder 
mit ihnen Ubergeordneten Funktionseinheiten HWE-1 in der HWE. 

Figur 5 veranschaulicht die bereits erwahnte vorteilhafte 
Unterteilung des vierten Moduls CD in mehrere 

Funktionseinheiten; diese werden in Bezug auf das vierte Modul 
auch Komplexgeratetreiber CD-i mit i = l... N genannt. Jeder 
dieser Komplexgeratetreiber wird seinerseits vorteilhafterweise 
in ein Geratetreiber-Element CD-GT und in ein Hardwaretreiber- 
Element CD-HW unterteilt. Die Elemente CD-GT sind uber die 
Schnittstelle M3 an das erste Modul ASW angeschlossen. Ober 
diese Schnittstelle M3 werden Softwares ignale iibertragen, welche 
eine physikalische GroAe, wie zum Beispiel die Einspritzmenge 
Oder Drehzahl reprasentieren. Wenn die Geratetreiber-Elemente 
CD-GT ein solches Sof twaresignal von dem ersten Modul ASW 
empfangen, wandeln sie dieses in ein anderes Softwares ignal um, 
welches spezifisch ist fur einen anzusteuernden Aktor, aber noch 
unspezifisch ftir die Steuergerate-Hardware ist. Im umgekehrten 
Fall, wenn die Geratetreiber-Elemente CD-GT ein derartiges 
anderes Softwaresignal von einem Hardwaretreiber-Element CD-HW 
empfangen, wandeln sie dieses in ein Softwaresignal um, welches 
nur eine physikalische Grofie reprasentiert, aber nicht mehr 
spezifisch ist fur einen Sensor, von dem es urspriinglich erzeugt 
wurde. Die Hardwaretreiber-Elemente CD-HW dienen zum direkten 
Anbinden der speziellen Sensor-/Aktor-Konfiguration 200 an die 
verwendete Steuergerate-Hardware, insbesondere an den 
verwendeten Prozessor 100a-l. Zwischen den Geratetreiber- 
Elementen CD-GT und den zugehorigen weiteren Hardwaretreiber- 
Elementen CD-HW sind jeweils Schnittstellen Ei mit i = 1...N 
vorgesehen. 

Einer der Komplexgeratetreiber ist die einleitend beschriebene 
Funktionseinheit Aggregate-Positions-Management EPM. Ihr 
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Geratetreiber-Element und ihr Hardwaretreiber-Element erhalten 
zum Zwecke einer eindeutigen Zuordnung die Bezugszeichen CD EPM -GT 
und CDepm-HW. 

Figur 6 veranschaulicht beispielhaft die Modulschnittstellen M2 
und M4. Die Pfeile reprasentieren jeweils die durch die 
Schnittstellen realisierten Abhangigkeiten zwischen den 
gezeigten Modulen oder deren Komponenten. Dabei bedeutet die 
Aussage, dass ein Modul abhangig von einem weiteren Modul oder 
eine Komponente abhangig von einer weiteren Komponente ist, dass 
dieses Modul auf das weitere Modul oder diese Komponente auf die 
weitere Komponente zugreift beziehungsweise dem weiteren Modul 
Oder der weiteren Komponente Daten zur Verarbeitung in Auftrag 
gibt. Die die Abhangigkeiten reprasentierenden Pfeile stellen 
nicht zwangslaufig auch die entsprechenden Datenflussrichtungen 
dar; diese werden beispielhaft weiter unten mit Bezugnahme auf 
Figur 8 erlautert. Aus Figur 6 ist zu erkennen, dass zwischen 
dem dritten Modul DE und dem ersten Modul ASW eine 
wechselseitige Abhangigkeit besteht. Die Abhangigkeit des ersten 
Moduls ASW von dem dritten Modul DE, reprasentiert durch den 
Pfeil, der von dem zweiten Modul zu dem ersten Modul orientiert 
ist, resultiert aus der Tatsache, dass das erste Modul darauf 
angewiesen ist, dass das dritte Modul DE zum Beispiel ein 
Sensorsignal und/oder ein zugeordnetes Qualitatssignal, welches 
eine Information uber die Qualitat des Sensorsignals 
reprasentiert, far das erste Modul ASW bereitstellt . 

Wie aus Figur 6 weiterhin zu erkennen ist, realisiert die vierte 
Modul-Schnittstelle M4 einseitige Abhangigkeiten der 
Infrastruktur-Komponente und der Hardwarekapsel-Komponente 
gegenuber dem dritten Modul DE und eine wechselseitige 
Abhangigkeit zwischen der Kommunikations-Komponente COM 
gegenuber dem dritten Modul DE. Alle drei genannten Komponenten 
sind dem zweiten Modul CO zugeordnet. Die einseitige 
Abhangigkeit der Infrastruktur-Komponente und der 
Hardwarekapsel-Komponente bedeutet, dass auf das dritte Modul DE 
auf diese Komponenten zugreift, urn dort Daten verarbeiten zu 
lassen. Analoge Abhangigkeitsbezeichnungen, wie sie soeben fur 
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die Schnittstelle M4 zwischen dem zweiten Modul CO und dem 

dritten Modul DE beschrieben wurden, bestehen auch fur die 

Schnittstelle M6 zwischen dem zweiten Modul CO und dem vierten 
Modul CD. 

i 

Pigur 7 zeigt ein Beispiel fur eine komponententibergreifende 
Kommunikation zwischen zwei Funktionseinheiten in 
unterschiedlichen Komponenten desselben Moduls. Genauer gesagt 
veranschaulicht Figur 7 eine Kommunikation zwischen der 
Funktionseinheit Signalaufbereitung HWE-1 innerhalb der 
Hardwarekapsel-Komponente HWE und der Funktionseinheit 
Diagnosemanager IS-3 innerhalb der Infrastruktur-Komponente IS 
Hier ist die Funktionseinheit Signalaufbereitung abhangig von 
der Funktionseinheit Diagnosemanager. Dies kann zum Beispiel 
bedeuten, dass die Funktionseinheit Signalaufbereitung HWE-1 ein 
Signal an die Funktionseinheit Diagnosemanager IS-3 sendet mit 
dem Auftrag urn Bearbeitung. Das gesendete Signal reprasentiert 
zum Bexspiel einen Defekt in der dem Steuergerat 100 
zugeordneten Hardware 100a. Mit der Obersendung des Signals 
beauftragt dann die Funktionseinheit Signalaufbereitung HWE-1 
die Funktionseinheit Diagnosemanager, dieses Signal 
aufzubereiten, das heiflt zum Beispiel zu entprellen, so dass 
erne fehlerfreie Auswertung dieses Signals moglich wird. Neben 
der Signalaufbereitung kommt dann der Funktionseinheit 
Diagnosemanager zum Beispiel auch die Aufgabe zu, dieses Signal 
abzuspeichern, so dass es zu einem spateren Zeitpunkt, zum 
Beispiel in einer Kf z-Werkstatt, zwecks Fehlerdiagnose 
ausgelesen werden kann. 

Figur 8 veranschaulicht schliefilich das Zusammenwirken der 
emzelnen Module innerhalb der Steuergerate-Sof tware 100b anhand 
ernes beispielhaften Verlaufs von Signalen. Eine derartige 
Signalverlaufsbetrachtung ist eine alternative Moglichkeit zur 
Beschreibung der Funktionen einzelner Schnittstellen 
msbesondere zwischen den Modulen, im Vergleich zu der oben 
bereits erwahnten Abhangigkeitsbetrachtung. Beide 
Betrachtungsweisen sind keineswegs widerspruchlich zueinander 
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sondern beschreiben lediglich die r, m v+i 

auf unterschiedliche Weise Funkt — emer Schnittstelle 

Konkret 1st in Figur 8 derjenige Signalverlauf dargestellt H 
s.ch ergiht, wenn der Fahrer eines Fahrzeugs, in llZtls ' 

Brennkraftmaschine 300 mit dem Stsueroerflt l n k 
das Gasoedal v^h*-- 4. „ ^euergerat 100 emgebaut 1st, 

- — it. s = :r: ^^r- 

S (- p11nn „ , 3 ' wei cnes die verdnderte 

stellung des Gaspedals reprasentiert ™s ^ , 

—st in die Hardware 100a 

welche 2 un a l n r rS T al U "*~" in e ^ Softwaresignal, 

elches zunachst noch steuergeratespezif isch ist. Dieses 
Softwaresignal S2 verlassi- j. ses 

100a „n rf , ■ „ • Verlasst alsdann die Steuergerate-Hardware 
X00a und wird in das zweite Modnl m „ 

Hardwarek aD , P i v ' genauer gesagt in dessen 

Hardwarekapsel-Komponente HWE eingespeist. Dort erfahrt da, 
Softwaresignal eine Aufbereitung in der Weise, dassdL in ihm 
noch enthaltenen Einflusse der Steueraerate »' 7 
ihm entfernt werden. Am Ausgang IThI^T * ^ 

HWE liegt dann k • • Hardwa rekapsel-Komponente 

, . 9 J ^ Sln bereinxgtes Softwaresignal an, welches 
.nsbesondere keine Prozessorspezif ika mehr enthSit Es 
reprasentiert jedoch nach wis vor noch die CharlkterLti, h 
ursprunglichen elektrischen Signals ^ rakteristlka des 

Gaspedalstell„™ » Sl 9nals, namlich die veranderte 

^speaaistellung, zum Beispiel in Form einer Amr,n * * 
Dieses bereinicte sinn.i „ . . Amplitude von 3 V. 

, phnlff r ^ nigte Sl 9nal S3 wird dann iiber die Modul - 
Schnittstelle M4 dem dritten Modul DE zugefuhrt Z h„ h 

S^trr ber6inigte S ---^--Ti r n t 'dL% d e T S e dritten 
di r;:: ; t S :; s ^ n ; o i r n ; sche Ebene bezo g en auf 

Signal S4 am Ausgang des dritt^S^'^. T T/^^ 

:i P z:^ri des dritten Moduis - ~ ' tz ::,: ignal 

reprasentierte veranderte st-pn„n« ^ 

zum Beisoiel in m ste Hung des Gaspedals als Ist-GreiJe 

oeispiei an Form von 75 % h^q m x rt i . u 

Gaspedals reprasentiert Its \t T ' ° rehwinkels d « 

der SchnittsLlle ^ z^schen d S " ±St Teil 

-L-te M2 zwischen dem ersten Modul ASW und dem 
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Written Modul de p<s f it u„. 

«*. Modul asw, -zt i:zr n r::™ 1 direkt in 

BrennkrafJ"! \ o Mome ntenanforderung far die 
Brennkraftmaschme 300. Sie koordiniert diese 
Momentenanforderung von dem dritten Modul »!! 
vorhandenen anderen Mo m entenanfordLunaen d eV6ntUe11 
Modulen, Ko.ponenten ode r 

Brennkraftmaschine oes t,m- ^ ten an die 

ygregate Komponente EP auszugeben. 

Die Antriebaaggregate-Komponente EF fuhrt d„„„ • 
63 -P*-*—- Solidxebuomentes in von def ^ T 

erforderiioben Solidre_e s IXderi £ ^ . 
2WltM sts " 9 »»e„3ignal sio, weiobea die zur eLT" *" 
vorgegebenen SoUdrenmomentes erforderliohe ,7 U ™ 9 
auf physikaliaoher Eb e „e reprasenti^f f """""""ottmeng. 
generierte StellorM. repraSentlert • J« nachdem, ob die 

spezielien 1 ' / , nOIm * leD Akt ° r ° d « 

n AJCtor ^it komplexer Schnit-t-Qf^i 

9 ibt die Antriebaaggregate-Ko J„™EF die r^""" ist ' 
dritte Modul DE oder an daa viarte ModuT tr, Stell9r00e an 
beschriebenen Beisoiel i,f h aUS - In dem bish " 

-ateaerang .i-..^ 1 ^™"^ 1 ^ 86 2 « 
aich um ainen normalen AJctor ll v , vorgeaahen, bai dem as 
handelt. Oeabaib gibt die IntrLb " SChni ""*^ 
ersta SteUg reB en 5 ignal se^ rTjZZtlTT 0 ^ EF *" 
Critte Hodui DE aas. Oaa dritte Z j ZlT t d ll " " 
Physikalische StellgroJie Sfi rc wandelt emgegebene 

Sofi-w*^ • ■, x " LgroJJe S6 (Softwaresignal) urn in ein 

ala ktrischen 3 :;~^ rt " -Pezi f i S oben 

eprasentiert. Dieses Signal S7 wird 
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iiber die Modul-Schnittstelle M4 an das zweite Modul CO 
ausgegeben, wo es von dessen Hardwarekapsel-Komponente HWE in 
em Softwaresignal umgewandelt wird, welches ein fur die 
Steuergerate-Hardware 100a spezifisches elektrisches Signal 
reprasentiert. Bei dieser Umwandlung kann es sich beispielsweise 
urn eme an die Anforderungen der Steuergerate-Hardware 
angepasste Quantisierung handeln. Das von der Hardwarekapsel- 
Komponente HWE erzeugte und ausgegebene Signal S8 wird der 
Steuergerate-Hardware 100a zugeftihrt, welche dieses Signal in 
exn reales elektrisches Signal zur Ansteuerung des 
Druckregelventils 200b2 als Aktor umwandelt. 

Parallel zu der Bearbeitung des ersten StellgroAensignals S6 
erfolgt in dem beschriebenen Beispiel die Bearbeitung des 
zweiten Stellgrofiensignals S10 durch das vierte Modul CD, 
nachdem es dorthin tiber die Modul-Schnittstelle M3 ubertragen 
wurde. Das vierte Modul wandelt das Signal S10, welches die zur 
Realxsierung des angeforderten Solldrehmomentes erforderliche 
Sollkraftstoffmenge in physikalischer Form reprasentiert, in ein 
Softwaresignal um, welches ein fur die Steuergerate-Hardware 
100a spezifisches Signal reprasentiert. Insofern ubernimmt das 
vxerte Modul CD gleichzeitig die Funktion des dritten Moduls und 
der Hardwarekapsel-Komponente fur spezielle Aktoren mit 
komplexerer Schnittstelle, wie es ein Einspritzventil 200bl zur 
Exnatellung der Kraftstof fmenge darstellt. Das beschriebene, von 
dem vierten Modul CD ausgegebene Softwaresignal Sll wird dann 
ebenfalls der Steuergerate-Hardware 100a zugeftihrt, damit diese 
das empfangene Softwaresignal in ein reales elektrisches Signal 
S12 zur Ansteuerung des Einspritzventils 200bl als Aktor 
umwandelt. Die so erfolgte Ansteuerung des Druckregelventils 
200b2 und des Einspritzventils 200bl bewirken zusammen eine 
Veranderung des Drehmomentes der Brennkraftmaschine 300 im 
Hmblick auf den durch die veranderte Gaspedalstellung 
reprasentierten Fahrerwunsch beziehungsweise auf das diesen 
Fahrerwunsch reprasentierende Solldrehmoment . 
WUrde es sich bei der Brennkraftmaschine 300 nicht um eine 
Dieselmaschine, sondern um eine Benzinmaschine handeln, so 
warden von der Antriebsaggregate-Komponete EF drei 
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Stellgrdfiensignale erzeugt. Das erste Stellgrdfiensignal S6, 
welches auf das dritte Modul DE ausgegeben wird, reprasentiert 
einen Sollwert ftir die einzustellende Luftmasse und das zweite 
auf das vierte Modul ausgegebene Stellgrdfiensignal S10 
reprasentiert die zur Realisierung des Solldrehmomentes 
erforderliche Sollkraf tstof fmenge . Weiterhin wird ein drittes 
Stellgrofiensignal S13, ebenfalls von der Antriebsaggregate- 
Komponente EF an das vierte Modul CD ausgegeben, wobei das 
Stellgrbfiensignal S13 den Ztlndzeitpunkt ftir die Zundkerzen der 
Brennkraftmas chine definiert. 

Das erste Stellgrdfiensignal S6 dient nach einer Umwandlung in 
die Signale S7, S8 und S9 zur Ansteuerung der Drosselklappe, das 
zweite Stellgrofiensignal S10 dient nach einer Umwandlung in die 
Signale Sll und S12 wiederum zur Ansteuerung des 

Einspritzventils und das dritte Stellgrofiensignal S13 dient nach 
einer Umwandlung in die Signale SI 4 und S15 zur Ansteuerung 
einer Zundkerze 200b3. Die in Figur 8 innerhalb der Module Oder 
Komponenten gezeichneten gestrichelten Linien veranschaulichen 
lediglich die Zuordnungen von Eingangssignal zu Ausgangssignal . 
Sie schliefien eine Bearbeitung der Eingangssignale innerhalb der 
Module oder Komponenten ausdrucklich nicht aus. 

Die Funktionseinheiten, Komponenten oder Module werden 
vorzugsweise als Computerprogramme realisiert. Dann ist es 
moglich, diese Computerprogramme, gegebenenfalls zusammen mit 
weiteren Compute rprogrammen zur Steuerung der Antriebsaggregate, 
auf einem computerlesbaren Datentrager abzuspeichern. Dabei kann 
es sich urn eine Diskette, eine Compact Disc, einen sogenannten 
Flash-Memory oder dergleichen handeln. Die auf dem Datentrager 
abgespeicherte Software kann dann als Produkt an einen Kunden 
verkauft werden. Aufierdem ist es im Fall einer 
Softwarerealisierung mdglich, das Computerprogramm, wiederum 
gegebenenfalls zusammen mit weiteren Compute rprogrammen, auch 
ohne die Zuhilfenahme eines Datentragers iiber ein elektronisches 
Kommunikationsnetzwerk als Produkt an einen Kunden zu ubertragen 
und auf diese Weise zu verkaufen. Bei dem Kommunikationsnetzwerk 
kann es sich zum Beispiel urn das Internet handeln. 
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In ewer speziellen Erweiterung der bisher be.snhr' u 
AusfUhrungsformen wird nun konL.t- ^chrxebenen 
Zuordnung der Bin- und a ^ Konfi ^ation und 

ng aer Em- und Ausgangssignale der Module ir^ Q ^ 
DE und CO sowie auf deren Eu^h,. module, insbesondere 

zwischen.odul bzw. e^ne L. h ^ abgehoben ' Da *ei wird ein 
eine « nori „„.„ „. , enscnicnt SZS eingefllhrt, welche 

' aer Signale zwischen den Modulen i,.k. 

aind » leder die Module CD ^ r 10 *>rgestellt. Darin 

dargesteiit. 2wisohen den Modulen co un^DE wird' 3 

zur Strukturierung "on ^ °™ 

Modui zu/signa^rr 'a : e^TLtTz^l" ^ 
SZS . Diese <37<? ««- ^ Sl 9nal-Zuordnung-Schicht 

uiese SZS ist der Hardwarenaheren flr*h-?^4- 
CO zugeordnet. Des weiteren . . nahe "» Schlcht ' ^so dem Modul 

ozw. die gesamte KSS kann nun eino ,n ese SZS 

Signalzuordnung erfola e n " * allgeraeine und flexible 

™ g er folgen, so dass das Modul rn ^ « , 

unabhangig von ihr e n m itei„a„der auage^uachten Ein „ d " 
Ausgangasignalen bz„. deren konkrete. " US ° hte " Ein " und 

werden kdnnen, da die korrekte Signal ^nzipiert 
ty, • ^ irejcle Signalzuordnung in ein*r* 

Zwischen-Schicht, dent Modul SZS erfolgt. . 

Bei einer ausgewahlten Darstellung erfolat dio v 

Modulen vorteilbaf ter W eise Uber ein xm! Besl > V ° n 
Konfigurationsparameter, die durch 2nT a der 
entsprechende *. c - und * h n 7 Konfl ^ra tl onsgeneratoren in 

Decent bescbreL d ie ^^^^T "~» 

Drgztai input/Output ,D I0) uber XML-basierte Textdateien I 

» gnaikiaase DIO definiert. Die Beachreibung der DIO- 
Eigenachaften wird auf verschiedenen Srh.^ T 
Einerseits werden DIO-signaie ItTT Arbe " Sebenen *"chgefahrt. 
Device Encapsulation (deT^ T n T PZO ' ekt ' m ^^en 
Initialiaierungawert nd ^u^™"" R j Ch — 

'DIO_SIGNAL REQUEST) , ander!rse its *u 
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mussen auf die entsprechende Hardware geroutet „ h 
(DIO_Sl GNAL _ RODTING) . Angeforderte „ j tfc WSrden 
crleich-f^iio ^ *• . ^«J-L.e hardware Pins mUssen 

glexchfaUs *o„f lguriert werden (DIO_SIGNAL_IMPLEMENT) . 

^^^^^^ 

Bei der Beschreibung der digitalen Pin 

zwischen Device Encapsulation (DE> HaV "±*d 

(HAL= SZS) un n H , ^ Hardwar e Abstraction Layer 

oie 5 e LoL"L;;r S iT i r ation <Modui co) 

Schichten bzw i s , ^ aU< * 2WiSChen 

optiona! * Be^pieTLTh" 6 " ^ — -« • 

ok ^ KSS4 od :rLw u „t r:r "i s r: co ais kss3 ° d ~ * sw - 

°abei 1st iMner „ le bei Jr !'! f 55 Sowle CD ™* M .1. KSS2 . 
Hardware Configuration - ^sangs.aodul „ le n ier co als 

-ror de run 3S ::r tr-e^itrr" 1 ' wie de bei kss mit 

Grundstruktur ist ^ auf ^ " ,ttalt « " M — 

Konfigurationsschnittstellen km k- ,„„ 

weiteren wird nur die KSS ^ ' «bertragbar. i m 

beschri*h«n ^ ■ ' S ° C ° Und DE ketreffend 

beschneben, wobei dadurch die Anwendbarkeit di« «x ■ 
Schnittstellen KSS2-Ksqs al w encU5arkeit die ubrigen 
wird. 5 6benS ° v "anschaulicht angesehen 

Die relevanten Konf igurationsparameter fur die 

:=~.ti ™::::zr* akt und 

auf dieser Ebene W!p L : e ^:? ^angasignalan sind 
und der lnitiali si eru„gs„ert von J- Richtu "9 
Sicht der Ko^onantau^e: LL RouTm- T ^ " 
Kataenbedingungen vorauagaaat," aul ^1 ch f* ^ ** 
Ko.poaententreiber spatj iaufal aoii """"^ ** 

Die ^Configuration der HAL umfasst das Routing des sicn.l 

auf die entsprechende Hardware in *i S^gnalnamens 

Signal ein Generischer Harden dem 

cner Hardwarepxnnamen zugewiesen. 
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Die Hardware-spezifischen Konf igurationseinstellungen warden. auf 
unterster Ebene vorgenommen. Die Konf igurationsparameter dieser 
Ebene beziehen sich auf das entsprechende Modul bzw. auf die 
Signalklasse und lassen sich bereits nicht mehr Projekt- und 

5 Hardware-unabhangig betrachten. Die Zuordnung der Signale 

geschieht iiber die Angabe des Hardwaremoduls (z.B. ADC, GPIO 
Oder CY310, CY100, etc.) mit dem gewunschten Port bzw. Pin auf 
diesem Modul. Beim ADC Modul muss zusatzlich noch die 
Schwellspannung angegeben werden, die tiber High oder Low 

0 entscheidet. 



Das Einstellen von Registerwerten erfolgt uber die Konfiguration 
der Port Hardware Schicht (Layer) . Auf dieser Ebene kommen 
Modul-ubergreifende Anforderungen zusammen. Beispielsweise 
existieren far die Parallel Schnittstelle Anforderungen von 
verschiedenen Modulen bzw. Signalklassen (GPIO, GPTA, SSC, CAN, 
etc.). Aus diesem Grund konnen Hardwareeinstellungen nicht 
Modul-spezifisch in einer Signalklasse erfolgen (siehe auch 
Konf igurationsprozess) . 

Die DIO-Konfiguration findet somit auf unterschiedlichen 
Konf igurationsebenen statt: 

- Device Encapsulation DE: Anforderung eines Signals 

- Hardware Encapsulation/HAL=SZS : Routing eines Signals 

- Hardware Configuration CO: Konfiguration der Hardware Schicht 

Die drei Schichten der Konfiguration 
Schicht /Datei /Inhalt 

DE / paketnamexm) I Signalname, Richtung (IN.OUT), Applizierbarkeit bzw. 
Einstellung der Zugriffsart (Makro oder Funktion) 

SiM^^Hl ' P ro > rfxml / Signalname, Hardware Modul, Port, Pin, 
[SCHWELLWERT(ado] 

Hardware Configuration / hardware. xm I / Hardwareelgenschaften 
Registereinstellungen 

Die Aufteilung der Konfiguration in verschiedene Ebenen 
beschrankt sich nicht nur auf das Konf igurieren digitaler Ein- 
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und Ausgangssignale bzw. des DIO-Moduls, auch in anderen Modulen 
(ADC, PWM) erfolgt die Konfiguration entsprechend obiger 
Klassifizierung einschliefilich etwaiger Abweichungen. 

Die Namen der XML-Konf igurationsdateien sind im Grunde genommen 
frei wahlbar. Innerhalb der DE wird sicherlich eine Vielzahl an 
paketorientierten Konf igurationsdateien entstehen. Auf HAL-Ebene 
kann das Signal-Routing entweder in einer zentralen XML-Datei 
Oder aber auf verschiedene Konf igurationsdateien verteilt 
werden. Hierbei muss es sich noch herausstellen, welche 
Aufteilung sich am besten fur die Strukturierung der Projekt- 
spezifischen Konfiguration eignet. Dasselbe gilt auch fur die 
Einstellung der Hardware bzw. Registerkonfigurationen. 



Anforderung eines Signals 

XML-Beschreibung ftir DIO (Paketschicht - DE) 

<CONP> 

<DIO> 

< D 1 0_S I GNAL_RE QUE S T > 

<DESC>Break signal</DESC> 

<dio__signal_name>e_a_bj?jk/dio signal name> 
<dio_dir>jj\k/dio__dir> "~ ~~ 

<dio_calibration>y.&s</dio calibration 
<dio_init>high</dio init>~~ 

</DIO_SIGNAL REQUEST> 
</DIO> 
</CONF> 



Auf dieser Ebene wird vom Paket aus der DE ein Signal 
angef ordert . 

Jedes Paket kann eine oder mehrere XML-Datei (en) mit beliebigem 
Dateinamen anlegen und digitale Ein- und Ausgangssignale vom 
Core/Hwe/Dio-Modul anfordern bzw. reservieren. Dazu muss die 
Paketsyntax aus der XML-Beschreibung far DIO (Paketschicht - DE) 
in diese XML-Datei (en) kopiert und angepasst werden. 

In obigem Beispiel wird festgelegt, dass ein Signal mit dem 
Namen "e_A_BRK" im Paket "DIO" verwendet wird, es eine bestimmte 
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Richtung hat (hier "in" fur Eingang) und applizierbar 
(Applizierbar bedeutet, dass das Signal-Routing zur Laufzeit 
anhand einer Signaltabelle stattfindet und somit wahrend des 
Betriebs verandert werden kann. Werden die Signaldaten 
5 ausschliefilich zur Compilezeit festgelegt, so konnen Signale zur 
Laufzext nxcht mehr umgeleitet werden.) ist Oder nicht (hier 
"YES" far applizierbar) . Die Konf iguration verschiedener Signale 
kann in einer XML Datei beliebig oft wiederholt werden. 

10 Anxnerknng : 

Die Tags DIO_CALIBRATION und DIO_INIT sind optionale Tags. Diese 
sollten nur dann definiert werden, wenn aus der DE-Schicht schon 
im Vorfeld Anforderungen an Zugriffsart bzw. Initialisierung 
existieren. Bei diesen Tags handelt es sich um einen Wunsch an 
d le Konf iguration . Werden auf der HW-Ebene abweichende 
Einstellungen vorgenommen, so werden die Anforderungen aus der 
DE-Schicht uberschrieben und in der Report-Datei 
nvitprotokolliert (siehe auch Auszug aus der Datei 
tmp/include_tmp/dio_report . txt ) . 



.5 
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eines Signals 
XML-Beschreibung ftir DIO (Projektschicht . HAL) 

<CONP> 

<DIO> 

<D IO_S IGNAIi_ROUTING> 

<DESC>Break signal</BESC> 
<DIO_SOURCE>£_ A_BRK< /DIO SOURCE > 
<DIO_TARGET>GPJO P8 PO IN< /DIO TARGET> 
</DIO SIGNAL ROUTING>~ ~ ~ - 
</DIO> ~ ~ 
</CONP> 

Auf dieser Ebene wird vom Projekt das Signal-Routing 
durchgefuhrt. Der Software Signalname wird sozusagen einem 
Hardwarepinnamen zugewiesen. Dieser Hardwarepinname ergibt sich 
aus der gewUnschten Hardware-Ressource, welche in der Hardware 
Schxcht konfiguriert wird (siehe Konf iguration der Hardware 
Schicht) . 
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beliebig oft wiederholt warden '"^ ^ Date± 
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Konfiguration der Hardware Schicht 

■ 

XML-Beschreibung fur DIO (Hardware Schicht) 

<CONF> 

<DIO> 

signal</ DBSC> <DESC>Aa ^are resource for break 

<DIO MODULE>GPJO</DIO MODDLE> 
<DIO PORT>fi</DIO PORT> 
<DIO__PIN>0</DIO PIN> 
<DIO_DIR>JAK/ DX o DIR> 

</COHF> 

Die Hardware-Eigensohaften des TC177S/Tn 70* 

funktionalen Einstellungen getrenM U „T " *° n ^ 

Konfigurationssohiont (H 9 „ ZlTZTull Siner SeP " aten 

Pins , E n dstuf : n ~„: e b S e e a n t Und "° dUle ^ - 
Diese Module m us3e„ fU " aaa M «-"<*«"« —dnen. 

signals functional in der lao e AUS9ebM di9itaI « 

der XML-Beschreibung far D « L"^ "W" ^ ^ 
oatei .opiert und angepaa I TrZ ^ <U '" ^ 
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In obigem Beispiel wird festal ^ 
"GPXO" im Paket <> DIO „ L If* ^ ^ M ° dUl 

"GPIO P8 *>o rw* Beschreibung ( DESC) 

<*rj.o_P8_P0 in" verwendet ward I "n>™» , *. ^ 

d ( GPio" (steht far Paraliele 



rait dem Namen 
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Schnittstelle) . Von diesem Modul wird die Ressource (Port "8", 
Pin "0") angefordert und der Applikationsidentif ier "yes" sowie 
der Initialisierungswert "HIGH" zugewiesen (sofern dieses an 
dieser.Stelle ftir einen Eingang Sinn macht) . Die Konf iguration 
verschiedener Signale kann in einer XML Datei beliebig oft 
wiederholt werden. 



3 Der Hardwarepinname ist ein rein generischer Name, welcher einer 
Hardwareressource eindeutig zugeordnet und nach dem folgenden 
Muster zusammengestellt wird. 

< Modulname>J^<Portnummer>J><Pinnn 

2.B. GPIO_P8_P0_IN. 

Der Hardwarepinname Msst sich nach einem Konf igurationslauf der 
DIO Report Datei entnehmen (siehe nachfolgend Generischer 
Hardwarepinnamen) . 



Auszug aus der Datei tmp/incIude_tmp/dio_report.txt 

DIO Report 

Signal Map - Digital Input/Output Signals 

Signal name: OUTPUT 

HW Signal: GPI0_P9 PO OUT 
Module: GPIO ~* 
Port : 9 
Pin: 0 

Calibration : YES 

Signal name: INPUT 

HW Signal: GPI0_P9 P4 IN 
Module: GPIO ~ 
Port: 9 
Pin: 4 

Calibration: YES 

Signal name: INPUT2 

HW Signal: GPIO P9 P8 IN 
Module: GPIO — — — 
Port: 9 
Pin: 8 
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Calibration: YES 

Anmerkungen 



Es wird deutlich, dass die xmi-fi™ * 

<DIO INIT> in ieweil. Elemente <DIO_CALIBRATION> und 

- T> ln 3 ew eils zwei unterschiedlichen 
vorto^en. Beide XML-Element, sind optional t ! 
nioht expli.it angegeben warden wird von foLn' ""^ 
Einstellungen ausgegangen: folgenden Default- 

Kommen diese XML-Elements • ^ 

eine, signals, , als "cn bal der <*n^~ung 
'■5 Sohicht vor, so sind die VsL^l Configuration der Hardware 

«* Pro^tebene nd^rprio " „ ^iL" 

rrojektebene spezifische Einstellunoer T""' *' die 
gegenuber der DE-SrfW ,-,„. ^ lnStellun 9 en vornehmen und auoh 

werden m itprotoLHL1 ^ ^rlappungen 
0 eingesehen werden! K °"«9«ationslauI 

Registries der XML-Konfigurationsdatei 

Dateien in die Jeweili^ ^ XML— 

singetragen werden, silhe Zrld ^ *" Ele "" ent C0W 

wen, siene Abbildung 5: Makefile mit- 

exngetragener XML-Konf igurationsdatei . 



# 

# Module definition 
# 

NAME 

INTERFACE 
CONP 

CSOURCES 

ASMSOURCES 

IMPLEMENTATION 
DATA 

SUBDIRS 



dio 
dio.h 
dio 



dio Tr St ' Xml di °- r ° uti ^-^ ^-Plement.^ 
aio.c gpio.c 



= diocfg 
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Eingabe der Konf igurationsdaten 

Die Eingabe der Konf igurationsdaten erfolgt uber einen XML- 
Browser (z.B. XMetal). Anhand einer Document Type Definition 
(DTD) far die Konfiguration des Miniprojektes wird die XML- 
Struktur vorgegeben. Die DTD fur die Konfiguration des 
Miniprojects liegt auf dem edc_hwe vob im Miniprojekt unter 
\scripts\xml\medcl7_conf.dtd. Diese DTD wird von den Entwicklern 
der Core Pakete (Module) entsprechend den bereit gestellten, 
konfigurierbaren Daten sukzessive erweitert. Die XML- 

Konfigurationsdateien mussen Uber diese DTD plausibilisert 
we r den . 



Durch die Aufteilung in verschiedene Konf igurationsebenen ist es 
mOglich, ohne detaillierte Kenntnisse fiber die 
Konfigurationsweise anderer Schichten, auf unterschiedlichen 
Ebenen Einstellungen vorzunehmen. 

Dabei mussen nur die Konf igurationsparameter angegeben werden, 
die fur die zu konf igurierend Schicht 
auch tatsachlich relevant sind. 

Das entsprechende Schichtenmodell ist in Figur 11 dargestellt. 

Anhand der Beschreibung digitaler Ein- und Ausgangssignale Wat 
S1 ch dieser Prozess recht anschaulich erlautern. In der obersten 
Schicht (DE) wird eine Signalanforderung an die Signalklasse DIO 
gestellt. Neben der Richtung, dem Initialisierungswert und dem 
Parameter Applizierbarkeit, ist es der Signalname, uber den die 
Anforderung aus der DE mit dem Routing in der HAL verkntipft 
wird. In der HAL kann nun der Signalname auf die entsprechende 
Ressource geroutet werden. Das Mapping mit den Einstellungen in 
der hwl erfolgt liber den Signalnamen bzw. Hardwarepinnamen des 
Pins. In der Hardware Layer muss neben dem Modulnamen auch der 
entsprechende Port bzw. Pin angegeben werden. 
Die Eigenschaften fur die PORT Hardware z.B. 
Registereinstellungen werden separat Uber die PORT- 
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v«teilt Oil K , ""•<* 1 ~« X^-Dateien 

vertent. Die Konfigurationsgeneratoren haben die Aufaabe df = 
Jco„ fi g Ur ierten Oaten zu tt berp r(lf en und diese zu 
plausibilisieren. 



Nach dem Aufruf des "mairo" k~,, n , 

Miniproiekt „< h \ xml2conf» -Kommandos i m 

Mmzprojekt W1 rd anhand der regis trierten XML- 

Konfagurationsdateien eine Dateiliste f,ir- *i a 
Konfiaurflin™^ *. • Ulste fur dle angemeldeten 

Lntrirr^ p ^ eneri "t. Darauf basierend samrnelt der 

zentrale XML-Parser far die Konf iguration (ehemals 
core parse.pl) alle Konfigurationsdateien bzw. .Daten ein i m 
^schluss an den Parsing-Prozess werden die individual l en " 

I" *Tko T generat ° ren ^""'^ U ^ 6ntS P-cnenden * c- 

und *.h-Konf lg urationsdateien erzeugt 

Die Konfigurationsgeneratoren prttfen zusatzlich die 

TftZlTT n : PlaUSibili3ieren die Benutzerdaten. Nach 

SionalT ^ ^ dSS " Makelaufs " *>nnen die konf igurierten 

cucigerate-code verwendet werden. 
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21. 02. 2003 

Robert Bosch GmbH, 70442 Stuttgart 



Anspruche 

1. Steuergerat (100) mit wenigstens einem Prozessor 
(100a-l) und wenigstens' einem Speicherelement (100a-2) zum 
Steuern eines Antriebsaggregates (300), insbesondere einer 
Brennkraftmaschine, eines Fahrzeugs mit Hilfe einer 
zwischen das Steuergerat (100) und dem Antriebsaggregat 
(300) geschalteten Sensor-/Aktor-Konf iguration (200), wobei 
die Steuerung durch eine Kommunikation zwischen einer 
Vielzahl von in dem Speicherelement (100a-2) hinterlegten 
Funktionseinheiten erfolgt; 

gekennzeichnet durch 

ein zweites hardwarenaheres Modul (CO) , das mit einem 
dritten hardwaref erneren Modul (DE) uber eine 
Signalzuordnungsschicht (SZS=HAL) verbunden ist, welche die 
digit alen Signale des einen Moduls dem anderen zuordnet, 
wobei hardwarenaher und hardwaref erner auf den Prozessor 
bezogen ist. 

2. Steuergerat nach Anspruch 1, dadurch gekennzeichnet, 
dass ein erstes Modul (ASW) , in dem diejenigen 
Funktionseinheiten zusammengef asst sind, die zur 
Beeinflussung des Antriebsaggregates im Ansprechen auf 
einen Benutzerwunsch auf physikalischer Ebene dienen, 
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enthalten ist. 



3. Steuergerat nach Anspruch 1, dadurch gekennzeichnet , 
dass das zweite Modul (CO),derart ausgebildet ist, dass in 
dem diejenigen Funkt ionseinheiten zusammengef asst sind, 
welche eine individuelle Programmierung der Hardware des 
Steuergerates in der Weise ermdglichen, dass die Hardware 
in die Lage versetzt wird, mit den Modulen des Steuergerats 
(100) zu kommunizieren und welche die Abarbeitung von 
Funktionen der Funktionseinheiten in den Modulen zeitlich 
koordinieren; und 

das dritte Modul (DE) , derart ausgebildet ist, dass in dem 
diejenigen Funktionseinheiten zusammengef asst sind, die 
eine individuelle Anpassung der verwendeten Sensor-/Aktor- 
Konfiguration (300) an das Steuergerat (100) in der Weise 
ermoglichen, dass zwischen den einzelnen Sensoren oder 
Aktoren der Konf iguration eine Kommunikation mit den 
iibrigen Modulen des Steuergerates moglich ist; und 

wobei zwischen den Modulen (CO, DE) Modul-Schnittstellen 
(Ml ... M5) fur eine modul -Qbergreif ende Kommunikation 
vorgesehen sind. 

4. Steuergerat (100) nach Anspruch 2 und 3, dadurch 
gekennzeichnet, dass das erste Modul (ASW) aufweist: 

- eine Fahrzeug-Komponente (VF) , in welcher diejenigen 
Funktionseinheiten zusammengef asst sind, die nicht 
spezifisch far einen bestimmten verwendeten Typ von 
Antriebsaggregat (300) sind; und 

- eine Antriebsaggregate-Komponente (EF) , in welcher 
diejenigen Funktionseinheiten zusammengefasst sind, die far 
den verwendeten Typ von Antriebsaggregat (300) spezifisch 
sind. 
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5. Steuergerat (100) nach einem der vorangegangenen 
Anspruche, dadurch gekennzeichnet, dass das zweite Modul 
(CO) aufweist: 

- eine Inf rastruktur-Komponente (IS) , in welcher diejenigen 
Funktionseinheiten zusanunengef asst sind, welche 
grundlegende Dienste anbieten oder reprasentieren, auf die 
andere Funktionseinheiten zugreifen kdnnen; und 

- eine Hardwarekapsel-Komponente (HWE) , in welcher 
diejenigen Funktionseinheiten zusammengefasst sind, welche 
eine individuelle Programmierung der Hardware (100a) des 
Steuergerates (100) in der Weise ermSglichen, dass die 
Hardware in die Lage versetzt wird, mit den Modulen (ASW, 
CO, DE, CD) des Steuergerats (100) zu kommunizieren. 

6. Steuergerat (100) nach Anspruch 5, dadurch 
gekennzeichnet, dass die Inf rastruktur-Komponente (IS) 
vorzugsweise die Funktionseinheiten Dienstebibliotheken 
(IS-1), Ablaufsteuerung (IS-2), Diagnosemanager (IS-3) 
und/oder Oberwachungskonzept (IS-4) umfasst. 

7. Steuergerat (100) nach einem der vorangegangenen 
Anspruche, dadurch gekennzeichnet , dass das Steuergerat 
(100) ein viertes Modul (CD) aufweist, in dem diejenigen 
Funktionseinheiten zusammengefasst sind, die eine direkte 
Ansteuerung von speziellen Sensor-Aktor-Konf igurationen mit 
komplexen Schnittstellen zu dem Steuergerat durch das erste 
Modul ermc-glichen. 

8. Steuergerat (100) nach einem der vorangegangenen 
Anspruche, dadurch gekennzeichnet, dass die 
Funktionseinheiten, die Komponenten und/oder die Module 
sowie die Schnittstellen zwischen ihnen zumindest teilweise 
als Computerprogramm ausgebildet sind. 
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9. Computerprogramm fur ein Steuergerat (100) gemafi ei 
der Anspriiche 1-7 zum Steuern eines Antriebsaggregates 

(300) eines Fahrzeugs, umfassend einen Programmcode, der 
geeignet ist, die Funktionseinheiten, Komponenten oder 
Module abzubilden und eine Kommunikation zwischen diesen 
zum Zwecke der Steuerung des Antriebsaggregates zu 
realisieren. 
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21.02.2003 

Robert Bosch GmbH, 70442 Stuttgart 



Steuergerat und Computerprogramm zum Steue rn eines 
Antriebs aggregates eines Fahrzeuqs 



Zusaramenf assung 

Die Erfindung betrifft ein Steuergerat (100) und ein 
Computerprogramm zum Steuern eines Antriebsaggregates (300) 
eines Fahrzeugs . Traditionell sind in einem derartigen 
Steuergerat (100) zahlreiche Funktionseinheiten vorgesehen, 
zum Beispiel eine Funktionseinheit Antrieb, 
Motor koordinator, Diagnosemanager et cetera. Um 
insbesondere im Falle eines Wechsels des von dem 
Steuergerat anzusteuernden Antriebsaggregates nicht alle 
Oder einen GroBteil der Funktionseinheiten, sondern nur die 
fur das neue Antriebsaggregat relevanten Funktionseinheiten 
austauschen zu miissen, wird erf indungsgemafi eine 
Modularisierung dieser Funktionseinheiten vorgeschlagen. 
Diese Modularisierung sieht insbesondere vor, dass 
diejenigen Funktionseinheiten zusammengefasst werden, die 
eine individuelle Programmierung der Hardware des 
Steuergerates in der Weise ermSglichen, dass die Hardware 
in die Lage versetzt wird, mit den Modulen des 
Steuergerates 100 zu kommunizieren. Figur 1 



Fig. 9 
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